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(54) Method and apparatus for securing digital assets 



(57) The present invention relates to digital assets 
which are in a secured form that only those with granted 
access rights can access. Even with the proper access 
privilege, when a secured file is classified, at least a se- 
curity clearance key is needed to ensure those who 
have the right security clearance can ultimately access 
the contents in the classified secured file. According to 
one embodiment, a secured file or secured document 
includes two parts: a header, and an encrypted data por- 
tion. The header includes security information that 



points to or includes access rules, a protection key and 
a file key. The access rules facilitate restrictive access 
to the encrypted data portion and essentially determine 
who the secured document can be accessed. The file 
key is used to encrypt/decrypt the encrypted data por- 
tion and protected by the protection key. If the contents 
in the secured file are classified, the file key is jointly 
protected by the protection key as well as a security 
clearance key associated with a user attempting to ac- 
cess the secured file. 
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Description 

[0001] The present invention relates to the area of 
protecting data in an enterprise environment, and more 
particularly, relates to a method and apparatus for se- 
curing digital assets (e.g. electronic data). 
[0002] The Internet is the fastest growing telecommu- 
nications medium in history. This growth and the easy 
access it affords have significantly enhanced the oppor- 
tunity to use advanced information technology for both 
the public and private sectors. It provides unprecedent- 
ed opportunities for interaction and data sharing among 
businesses and individuals. However, the advantages 
provided by the Internet come with asignificantly greater 
element of risk to the confidentiality and integrity of in- 
formation. The Internet is a widely open, public and in- 
ternational network of interconnected computers and 
electronic devices. Without proper security means, an 
unauthorized person or machine may intercept any in- 
formation travelling across the Internet and even get ac- 
cess to proprietary information stored in computers that 
interconnect to the Internet, but are otherwise generally 
inaccessible by the public. 

[0003] There are many efforts in progress aimed at 
protecting proprietary information travelling across the 
Internet and controlling access to computers carrying 
the proprietary information. Cryptography allows people 
to carry over the confidence found in the physical world 
to the electronic world, thus allowing people to do busi- 
ness electronically without worries of deceit and decep- 
tion. Every day hundreds of thousands of people interact 
electronically, whether it is through e-mail, e-commerce 
(business conducted over the Internet), ATM machines, 
or cellular phones. The perpetual increase of informa- 
tion transmitted electronically has lead to an increased 
reliance on cryptography. 

[0004] One of the ongoing efforts in protecting the pro- 
prietary information travelling across the Internet is to 
use one or more cryptographic techniques to secure a 
private communication session between two communi- 
cating computers on the Internet. The cryptographic 
techniques provide a way to transmit information across 
an insecure communication channel without disclosing 
the contents of the information to anyone eavesdrop- 
ping on the communication channel. Using an encryp- 
tion process in a cryptographic technique, one party can 
protect the contents of the data in transit from access 
by an unauthorized third party, yet the intended party 
can read the data using a corresponding decryption 
process. 

[0005] A firewall is another security measure that pro- 
tects the resources of a private network from users of 
other networks. However, it has been reported that 
many unauthorized accesses to proprietary information 
occur from the inside, as opposed to from the outside. 
An example of someone gaining unauthorized access 
from the inside is when restricted or proprietary informa- 
tion is accessed by someone within an organization who 



is not supposed to do so. Due to the open nature of the 
Internet, contractual information, customer data, exec- 
utive communications, product specifications, and a 
host of other confidential and proprietary intellectual 

5 property remains available and vulnerable to improper 
access and usage by unauthorized users within or out- 
side a supposedly protected perimeter. 
[0006] A governmental report from General Account- 
ing Office (GAO) details "significant and pervasive com- 

10 puter security weaknesses at seven organizations with- 
in the U.S. Department of Commerce, the widespread 
computer security weaknesses throughout the organi- 
zations have seriously jeopardized the integrity of some 
of the agency's most sensitive systems." Further it 

15 states: "Using readily available software and common 
techniques, we demonstrated the ability to penetrate 
sensitive Commerce systems from both inside Com- 
merce and remotely, such as through the Internet," and 
"Individuals, both within and outside Commerce, could 

20 gain unauthorized access to these systems and read, 
copy, modify, and delete sensitive economic, financial, 
personnel, and confidential business data..." The report 
further concludes "[intruders could disrupt the opera- 
tions of systems that are critical to the mission of the 

25 department." 

[0007] In fact, many businesses and organizations 
have been looking for effective ways to protect their pro- 
prietary information. Typically, businesses and organi- 
zations have deployed firewalls, Virtual Private Net- 
so works (VPNs), and Intrusion Detection Systems (IDS) 
to provide protection. Unfortunately, these various se- 
curity means have been proven insufficient to reliably 
protect proprietary information residing on private net- 
works. For example, depending on passwords to access 

35 sensitive documents from within often causes security 
breaches when the password of a few characters long 
is leaked or detected. Therefore, there is a need to pro- 
vide more effective ways to secure and protect digital 
assets at all times. 

40 [0008] This section is for the purpose of summarizing 
some aspects of the present invention and to briefly in- 
troduce some preferred embodiments. Simplifications 
or omissions may be made to avoid obscuring the pur- 
pose of the section. Such simplifications or omissions 

45 are not intended to limit the scope of the present inven- 
tion. 

[0009] The present invention is related to processes, 
systems, architectures and software products for pro- 
viding pervasive security to digital assets at all times and 

50 is particularly suitable in an inter/intra enterprise envi- 
ronment. In general, pervasive security means that dig- 
ital assets are secured at all times and can only be ac- 
cessed by authenticated users with appropriate access 
rights or privileges, and proper security clearance in 

55 some cases, wherein the digital assets may include, but 
not be limited to, various types of documents, multime- 
dia files, data, executable code, images and texts. Ac- 
cording to one aspect of the present invention, the digital 
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assets are in a secured form that only those with granted 
access rights can access. Even with the proper access 
privilege, when a secured file is classified, at least a se- 
curity clearance key is needed to ensure those who 
have the right security clearance can ultimately access 
the contents in the classified secured file. 
[0010] In another aspect of the present invention, the 
format of the secured file is so designed that the security 
information stays with the file being secured at all times 
or pointed to by a pointer in the file. According to one 
embodiment, a secured file or secured document in- 
cludes two parts: an attachment, referred to as a header, 
and an encrypted document or data portion. The header 
includes security information that points to or includes 
access rules, a protection key and a file key. The access 
rules facilitate restrictive access to the encrypted data 
portion and essentially determine who/how and/or 
when/where the secured document can be accessed. 
The file key is used to encrypt/decrypt the encrypted da- 
ta portion and protected by the protection key. If the con- 
tents in the secured file are classified, the file key is joint- 
ly protected by the protection key as well as a security 
clearance key associated with a user attempting to ac- 
cess the secured file. As a result, only those who have 
the proper access privileges are permitted to obtain the 
protection key, jointly with the security clearance key, to 
retrieve the file key to encrypt the encrypted data por- 
tion. 

[0011] In still another aspect of the present invention, 
the security clearance key is generated and assigned in 
accordance with a user's security access level. A secu- 
rity clearance key may range from most classified to 
non-classified. If a user has the need to access a se- 
cured file classified with a certain security or confidential 
level, a corresponding security clearance key with that 
security level is assigned therefor. In one embodiment, 
a security clearance key with a security level is so con- 
figured that the key can be used to access secured files 
classified at or lower than the security level. As a result, 
a user needs to have only one security clearance key. 
In still another aspect of the present invention, multiple 
auxiliary keys are provided when a corresponding se- 
curity clearance key is being requested. The security 
clearance key is the one being requested, generated in 
accordance with the determined security level and can 
be used to facilitate the access to a secured file classi- 
fied at a corresponding security or confidentiality level. 
The auxiliary security clearance keys are those keys 
generated to facilitate access to secured files classified 
respectively less than the corresponding security or 
confidentiality level. Depending on implementation, the 
security clearance key(s) may be further protected by 
means of secondary authentication, such as biometric 
information verification or a second password, to in- 
crease security level of the security clearance key(s). 
[0012] Depending on implementation and application, 
the present invention may be implemented or employed 
in a client machine and a server machine. Typically, if a 



user's access privilege (i.e., access rights) to a secured 
file is locally determined in a client machine, the present 
invention may be implemented as an executable mod- 
ule configured to operate locally, preferably, in an oper- 

5 ating system running in the client machine. If a user's 
access right to a secured file is remotely determined in 
a server machine, the present invention may be imple- 
mented as an executable module configured to operate 
in the server machine as well as in the client machine. 

10 [0013] Objects, features, and advantages of the 
present invention will become apparent upon examining 
the following detailed description of an embodiment 
thereof, taken in conjunction with the attached drawings. 
[001 4] These and other features, aspects, and advan- 

15 tages of the present invention will become better under- 
stood with regard to the following description, appended 
claims, and accompanying drawings where: 

FIG. 1 shows a diagram of securing a created doc- 
20 ument according to one exemplary secured file form 
used in the present invention; 
FIG. 2A shows a diagram of what is referred to here- 
in as a two-pronged access scheme according to 
one embodiment of the present invention; 
25 FIG. 2B shows a flowchart of a process for granting 
a proper security clearance level (i.e., a clearance 
key) according to one embodiment of the present 
invention; 

FIG. 2C shows a diagram of generating a clearance 
30 key according to one embodiment of the present in- 
vention; 

FIG. 2D shows a diagram of generating a clearance 
key according to another embodiment of the 
present invention; 
35 FIG. 3A illustrates an exemplary structure of a se- 
cured file according to one embodiment of the 
present invention; 

FIG. 3B shows an exemplary header structure of a 
secured file according to one embodiment of the 

40 present invention; 

FIG. 4 there is shown a flowchart of process for ac- 
cessing a secured document according to one em- 
bodiment of the present invention and may be un- 
derstood in conjunction with FIG. 3A and FIG. 3B; 

45 FIG. 5 shows a flowchart of a process for securing 
a file or document being created according to one 
embodiment of the present invention; and 
FIG. 6 shows an exemplary implementation of the 
present invention. 

50 

[0015] The present invention pertains to a process, a 
system, a method and a software product for securing 
electronic data or digital assets. According to one aspect 
of the present invention, secured files may be classified 
55 in several hierarchical security levels. To access the se- 
cured classified files, in addition to a user key, a user is 
assigned a clearance key that is based on at least two 
complementary concepts, "Need to Know" and "Sensi- 
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tivity Level" of the information in a secured classified file. 
According to another aspect of the present invention, 
the digital assets are in a form that includes two parts, 
one being an encrypted data portion and the other being 
a header including security information controlling re- 
strictive access to the encrypted data portion. The se- 
curity information employs access rules together with 
various cipher keys to ensure that only those with proper 
access privilege or rights can access the encrypted data 
portion. 

[0016] There are numerous advantageous, benefits, 
and features in the present invention. One of them is the 
mechanism contemplated herein capable of providing 
pervasive security to digital assets sought to be protect- 
ed at all times. Another one is that the digital assets are 
presented in such away that only those with proper ac- 
cess privilege as well as sufficient security clearance 
level can access information in the digital assets. Other 
advantageous, benefits, and features in the present in- 
vention can be readily appreciated by those skilled in 
the art from the detailed description of the invention pro- 
vided herein. 

[0017] In the following description, numerous specific 
details are set forth in order to provide a thorough un- 
derstanding of the present invention. However, it will be- 
come obvious to those skilled in the art that the present 
invention may be practised without these specific de- 
tails. The description and representation herein are the 
common means used by those experienced or skilled in 
the art to most effectively convey the substance of their 
work to others skilled in the art. In other instances, well- 
known methods, procedures, components, and circuitry 
have not been described in detail to avoid unnecessarily 
obscuring aspects of the present invention. 
[0018] Reference herein to "one embodiment" or "an 
embodiment" means that a particular feature, structure, 
or characteristic described in connection with the em- 
bodiment can be included in at least one embodiment 
of the invention. The appearances of the phrase "in one 
embodiment" in various places in the specification are 
not necessarily all referring to the same embodiment, 
nor are separate or alternative embodiments mutually 
exclusive of other embodiments. Further, the order of 
blocks in process flowcharts or diagrams representing 
one or more embodiments of the invention do not inher- 
ently indicate any particular order nor imply any limita- 
tions in the invention. 

[001 9] Embodiments of the present invention are dis- 
cussed herein with reference to FIGS. 1 - 6. However, 
those skilled in the art will readily appreciate that the 
detailed description given herein with respect to these 
figures is for explanatory purposes as the invention ex- 
tends beyond these limited embodiments. 
[0020] Generally, a content created by a creator for 
the purpose of an entity is an intellectual property be- 
longing to the creator or the entity. In an enterprise, any 
kind of information or intellectual property can be con- 
tent, though it is commonly referred to as "information" 



instead of "content". In either case, content or informa- 
tion is independent of its format, it may be in a printout 
or an electronic document. As used herein, content or 
information exists in a type of electronic data that is also 
5 referred to as a digital asset. A representation of the 
electronic data may include, but not be limited to, vari- 
ous types of documents, multimedia files, streaming da- 
ta, dynamic or static data, executable code, images and 
texts. 

w [0021] To prevent contents in electronic data from an 
unauthorized access, the electronic data is typically 
stored in a form that is as close to impossible as possible 
to read without a priori knowledge. Its purpose is to en- 
sure privacy by keeping the content hidden from anyone 
15 for whom it is not intended, even those who have access 
to the electronic data. Example of a priori knowledge 
may include, but not be limited to, a password, a secret 
phrase, biometric information or one or more keys. 
[0022] FIG. 1 shows an illustration diagram of secur- 
20 ing a created document 100 according to one embodi- 
ment of the present invention. One of the purposes of 
creating a secured file 1 08 is to ensure that the contents 
in the document 100 can be only accessed by or re- 
vealed to an authorized user with proper access privi- 
es lege. As used herein, the user may mean a human user, 
a software agent, a group of users or a member thereof, 
a device and/or application(s). Besides a human user 
who needs to access a secured document, a software 
application or agent sometimes needs to access the se- 
30 cured document in order to proceed forward. According- 
ly, unless specifically stated, the "user" as used herein 
does not necessarily pertain to a human being. 
[0023] After the document 100 is created, edited or 
opened with an application or authoring tool (e.g., Mi- 
ss crosoft WORD), upon an activation of a command, such 
as "Save," "Save As" or "Close", or automatic saving 
invoked by an operating system, the application itself, 
or an approved application, the created document 100 
is caused to undergo a securing process 101. The se- 
40 curing process 101 starts with an encryption process 
102, namely the document 100 that has been created 
or is being written into a store is encrypted by a cipher 
(e.g., an encryption process) with afile key (i.e., acipher 
key). In other words, the encrypted data portion 112 
45 could not be opened without the file key. For the purpose 
of controlling the access to the contents in the document 
1 00 or the resultant secured file 1 08, the file key or keys 
may be the same or different keys for encryption and 
decryption and are included as part of security informa- 
50 tion contained in or pointed to by a header 1 06. The file 
key or keys, once obtained, can be used to decrypt the 
encrypted data portion 1 1 2 to reveal the contents there- 
in. 

[0024] To ensure that only authorized users or mem- 
55 bers of an authorized group can access the secured file 
1 08, a set of access rules 1 04 for the document 1 00 is 
received or created and associated with the header 1 06. 
In general, the access rules 104 determine or regulate 
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who and/or how the document 100, once secured, can 
be accessed. In some cases, the access rules 104 also 
determine or regulate when or where the document 1 00 
can be accessed. In addition, security clearance infor- 
mation 107 is added to the header 106 if the secured 
file 108 is classified. In general, the security clearance 
information 107 is used to determine a level of access 
privilege or security level of a user who is attempting to 
access the contents in the secured file 108. For exam- 
ple, a secured file may be classified as "Top secret", "Se- 
cret", "Confidential", and "Unclassified". 
[0025] According to one embodiment, the security 
clearance information 1 07 includes another layer of en- 
cryption of the file key with another key referred to herein 
as a clearance key. An authorized user must have a 
clearance key of proper security level in addition to an 
authenticated user key and proper access privilege to 
retrieve the file key. As used herein, a user key or a 
group key is a cipher key assigned to an authenticated 
user and may be used to access a secured file or secure 
a file, or create a secured file. The detail of obtaining 
such a user key upon a user being authenticated is pro- 
vided in US Patent Application No. :1 0/074,804. 
[0026] According to another embodiment, the security 
clearance information 107 includes a set of special ac- 
cess rules to guard the file key. The retrieval of the file 
key requires that the user passes an access rule meas- 
urement. Since access privilege of a user may be con- 
trolled via one or more system parameters (e.g., a pol- 
icy), the access rule measurement can determine if the 
user has sufficient access privilege to retrieve the file 
key in conjunction with the corresponding user key. With 
the detailed description to follow, those skilled in the art 
can appreciate that other forms of the security clearance 
information 107 may be possible. Unless otherwise 
specified, the following description is based on the se- 
curity clearance information 107 being another layer of 
encryption with one or more clearance keys. 
[0027] In accordance with the security clearance in- 
formation 107, a user may be assigned a hierarchical 
security clearance level based on, perhaps, a level of 
trust assigned to the user. A level of trust implies that 
one user may be more trusted than another and hence 
the more trusted user may access more classified files. 
Depending on implementation, a level of trust may be 
based on job responsibility of the user or a role of the 
user in a project or an organization background checks, 
psychological profiles, or length of service, etc. In any 
case, a level of trust assigned to the user augments ad- 
ditional aspect to the access privilege of the user such 
that the user must have proper security clearance to ac- 
cess aclassified secured file even if the user is permitted 
by the access rules to access the file. 
[0028] As will be further described in detail below, un- 
less the level of security clearance of the user permits, 
a secured classified file (i.e., the file that is both secured 
and classified) may not be accessed even if the user 
has an authenticated user (or group) key and permitted 



by the access rules in the secured classified file. In one 
embodiment, the level of security clearance of the user 
is determined by one or more clearance keys assigned 
thereto. In general, a clearance key permits a user to 

5 access a secured file classified as "top secret", the same 
clearance key may permit the user to access all secured 
files classified less secure, such as "secret" or "confi- 
dential", where it has been assumed that the user has 
proper access privilege to be granted by the access 

10 rules in the file. In one embodiment, a clearance key is 
further secured by means of secondary authentication, 
such as biometric information verification and a second 
password. In other words, a clearance key may not be 
automatically released to or activated for a user upon 

15 an authenticated login, unless the user provides addi- 
tional information. 

[0029] In general, a header is a file structure, prefer- 
ably small in size, and includes, or perhaps links to, se- 
curity information about a resultant secured document. 
20 Depending on an exact implementation, the security in- 
formation can be entirely included in a header or pointed 
to by a pointer that is included in the header. According 
to one embodiment, the access rules 1 04, as part of the 
security information, are included in the header 1 06. The 
25 security information further includes the file key and/or 
one or more clearance keys, in some cases, an off-line 
access permit (e.g. in the access rules) should such ac- 
cess be requested by an authorized user. The security 
information is then encrypted by a cipher (i.e., an en/ 
30 decryption scheme) with a user key associated with an 
authorized user to produce encrypted security informa- 
tion 1 1 0. The encrypted header 1 06, if no other informa- 
tion is added thereto, is attached to or integrated with 
the encrypted data portion 1 1 2 to generate the resultant 
35 secured file 1 08. In a preferred embodiment, the header 
is placed at the beginning of the encrypted document 
(data portion) to facilitate an early detection of the se- 
cured nature of a secured file. One of the advantages 
of such placement is to enable an access application (i. 
40 e., an authoring or viewing tool) to immediately activate 
a document securing module (to be described where it 
deems appropriate) to decrypt the header if permitted. 
Nevertheless, there is no restriction as to where the en- 
crypted header 1 06 is integrated with the encrypted data 
45 portion 112. 

[0030] It is understood that a cipher may be imple- 
mented based on one of many available encryption/de- 
cryption schemes. Encryption and decryption generally 
require the use of some secret information, referred to 
50 as a key. For some encryption mechanisms, the same 
key is used for both encryption and decryption; for other 
mechanisms, the keys used for encryption and decryp- 
tion are different. In any case, data can be encrypted 
with a key according to a predetermined cipher (i.e., en- 
55 cryption/decryption) scheme. Examples of such 
schemes may include, but not be limited to, Data En- 
cryption Standard algorithm (DES), Blowfish block ci- 
pher and Twofish cipher. Therefore, the operations of 
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the present invention are not limited to a choice of those 
commonly-used encryption/decryption schemes. Any 
cipher scheme that is effective and reliable may be 
used. Hence, the details of a particular scheme are not 
further discussed herein so as to avoid obscuring as- 
pects of the present invention. 

[0031] In essence, the secured document 108 in- 
cludes two parts, the encrypted data portion 112 (i.e., 
encrypted version of the document itself) and the header 
1 1 0 that may point to or include security information for 
the secured document 108. To access the contents in 
the encrypted data portion 112, one needs to obtain the 
file key to decrypt the encrypted data portion 112. To 
obtain the file key, one needs to be authenticated to get 
a user or group key and pass an access test in which at 
least the access rules in the security information are 
measured against the user's access privilege (i.e., ac- 
cess rights). If the secured file is classified, it further re- 
quires a security level clearance on the user. In general, 
the security clearance level of the user must be high 
enough before the file key can be retrieved. Alternative- 
ly, part of the access rules may be left non-encrypted for 
users authorized or non-authorized alike to view embed- 
ded access permissions of a secured file in a display 
application or markup language interpreter (e.g., a 
browser). 

[0032] FIG. 2A shows a diagram 200 of what is re- 
ferred to herein as a two-pronged access scheme ac- 
cording to one embodiment of the present invention. To 
access a secured file 201 , a user needs to have access 
privilege based on a condition of "need to know" 202 
that is to be measured against by the access rules 204 
embedded in the secured file 201 . If the secured file 201 
is classified, the user must also have a higher security 
clearance level 206 that is measured against by the se- 
curity clearance information 206 (e.g., one or more 
clearance keys. In other words, there are at least two 
key holes 210 that must be "inserted" with two proper 
keys before the secured classified file can be accessed. 
[0033] FIG. 2B shows a flowchart 220 of process for 
granting a proper security clearance level (i.e., a clear- 
ance key) according to one embodiment of the present 
invention. The process 220 can be initiated with a re- 
quest for a clearance key. Depending on implementa- 
tion, the process 220 may be implemented in a machine 
(e.g., a central server, a local server or a client machine) 
that provides access control management to all secured 
files, perhaps, in an inter/intra enterprise environment, 
or a combination of a local client machine used by users 
and the machine. 

[0034] At 222, the process 220 awaits a request for a 
clearance key. It is described that a secured file can be 
classified or unclassified. When it is determined that a 
user needs to access a secured file that is classified, 
such request is provided to activate the process 220. In 
general, the request pertains to a specific user or some 
members in a group. At 224, a corresponding account 
for the user is retrieved, provided there is the account 



for the user. If the account is not available, then the ac- 
count shall be opened accordingly. Alternatively, the 
process 220 may be part of the process of opening an 
appropriate account for a user who has the need-to- 

5 know basis to access secured files at certain security or 
confidential level(s). Depending on implementation, the 
corresponding account information may include a user- 
name or identifier, membership information, designated 
access privilege, and a corresponding user key (which 

10 sometimes is a pair of a private key and a public key). 
At 226, a security level for the user is determined, which 
is usually done by the necessity. For example, an exec- 
utive of an enterprise may be assigned the highest se- 
curity clearance level and a front desk receptionist may 

15 be assigned the lowest security clearance level. Once 
the security level is determined, a clearance key is gen- 
erated at 228. 

[0035] Referring now to FIG. 2C, there is shown a di- 
agram 240 of generating a clearance key according to 

20 one embodiment of the present invention. A key gener- 
ator 244 receives one or more parameters 242 control- 
ling the security level determined at 226 of FIG. 2B to 
generate a sequence of alphanumeric or binary num- 
bers as a key. Whether using a secret-key cryptosystem 

25 or a public-key cryptosystem, one needs a good source 
of random numbers for key generation. The main fea- 
tures of a good source are that it produces numbers that 
are unknown and unpredictable by potential adversar- 
ies. There are many ways to generate such numbers, 

30 for example, random numbers can be obtained from a 
physical process. Another approach is to use a pseu- 
dorandom number generator fed by a random seed. In 
any case, depending on the input 242, the generator 244 
is configured to generate a clearance key of proper se- 

35 curity level. In one embodiment, the key generator 244 
generates keys 246 of different lengths or forms, each 
of the keys 246 corresponds to a security level, such as 
level 1 (highest security), level 2, level N (lowest se- 
curity). In another embodiment, each of the keys 246 

40 generated by the key generator 244 is embedded with 
a signature signifying a security level. Other methods of 
specifying a security level of a clearance key are possi- 
ble. Although it is possible to implement in such away 
that each clearance key with a certain security level can 

45 only access secured files classified in the same security 
level, it is preferable to permit a clearance key with a 
higher security level to access secured files classified 
in the lower security levels. In other words, a clearance 
key in level 1 (i.e., the highest security level primarily 

50 designated to secured files classified as "top secret") 
can be used to access all secured classified files 248, 
while a clearance key in level 2 can be used to access 
all secured classified files 248 except for those classified 
as "top secret". Likewise, a clearance key in level N can 

55 be only used to access secured files in security level N. 
One of the advantages for such arrangement is that a 
user needs only to have one clearance key, if the user 
has the need to access those secured classified files. 
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[0036] FIG. 2D shows a diagram of generating a 
clearance key according to another embodiment of the 
present invention. The key generator 244 receives one 
or more parameters 242 controlling the security level de- 
termined at 226 of FIG. 2B to generate a number of sets 
of alphanumericor binary numbers as a primary key 246 
and auxiliary keys 247. The primary key 246 is the one 
being requested, generated in accordance with the de- 
termined security level and can be used to facilitate the 
access to a secured file classified at a security or con- 
fidentiality level. The auxiliary keys 247 are those keys 
generated to facilitate the access to secured files clas- 
sified less than the security or confidentiality level. As 
shown in the figure, it is assumed that the primary key 
246 is for accessing a secured file classified at level 2. 
Accordingly, the auxiliary keys 247 can be respectively 
used to access secured files classified level 3, level 4, ... 
to level N, all less than level 2 in terms of security or 
confidentiality. To facilitate the description of the present 
invention, the following description is based on FIG. 2C 
and can be readily applied to FIG. 2D. 
[0037] Returning to FIG. 2B, after a proper clearance 
key is generated at 228, the clearance key is associated 
with the account at 230 so that the user will use the cor- 
rect key to access a secured file that requires a clear- 
ance key. The process 220 now awaits any call for the 
clearance key at 232. Depending on implementation, 
the clearance key may be stored locally or remotely and 
retrievable only when there is a need for it to access a 
classified secured file. In some cases, the clearance key 
can only be retrievable when a user passes a secondary 
authentication means. For example, a user is entitled to 
access certain secured files classified at least at a se- 
curity level. The clearance key associated with the user 
may be configured to be protected by means of second- 
ary authentication, such as biometric information verifi- 
cation or a second password, to increase security level 
of the clearance key. When a non-secured classified file 
is accessed, the clearance key is not needed and there- 
fore will not be released to or activated for the user. 
When a secured classified file is accessed, the process 
220 goes to 234, wherein the clearance key is released 
to the user to facilitate the retrieval of the file key in the 
secured file, provided the user has furnished necessary 
information or passed secondary authentication if need- 
ed. 

[0038] FIG. 3A illustrates an exemplary structure of a 
secured file 300 including a header 302 and an encrypt- 
ed data portion 304. Depending on implementation, the 
header 302 may or may not include a flag or signature 
306. In one case, the signature 306 is used to facilitate 
the detection of the security nature of a secured file 
among other files. The header 302 includes a file key 
block 308, a key block 31 0 and a rule block 31 2. The file 
key block 308 includes a file key 309 that is encrypted 
by a cipher with a protection key 320 (i.e., a doc-key key 
sometimes) and further with the clearance key 322 as- 
sociated with a user who attempts to access the secured 



file 300. Alternatively, the file 309 is encrypted with the 
clearance key 322 and then the protection key 320. The 
protection key 320 is encrypted and stored in the key 
block 31 0. In general, the key block 31 0 has an encrypt- 

5 ed version of the protection key 320 and can be only 
accessible by designated user(s) or group(s). There 
may be more than one key blocks in a header, wherein 
three key blocks are shown in FIG. 3A. To recover or 
retrieve the protection key 320, a designated user must 

10 have proper access privilege to pass an access rule test 
with the embedded access rules in the rule block 312. 
[0039] All access rules are encrypted with a user key 
(e.g., a public user key) and stored in the rule block 31 2. 
A user attempting to access the secured file uses must 

15 have a proper user key (e.g., a private user key) to de- 
crypt the access rules in the rule block 312. The access 
rules are then applied to measure the access privilege 
of the user. If the user is permitted to access the secured 
file in view of the access rules, the protection key 320 

20 in the key block 310 is retrieved to retrieve the file key 
309 so as to access the encrypted data portion 304. 
However, when it is detected that the secured file is clas- 
sified, which means that the file key can not be retrieved 
with only the protection key, the user must posses a 

25 clearance key. Only does the user have the clearance 
key, together with the retrieved protection key 320, the 
file key 309 may be retrieved to proceed with the de- 
cryption of the encrypted data portion 304. 
[0040] According to one embodiment, the encrypted 

30 data portion 304 is produced by encrypting a file that is 
non-secured. For example, a non-secured document 
can be created by an authoring tool (e.g., Microsoft 
Word). The non-secured document is encrypted by a ci- 
pher with the file key. The encryption information and 

35 the file key are then stored in the security information. 
[0041 ] According to another embodiment, the non-se- 
cured document (data) is encrypted using the following 
aspects, a strong encryption using a CBC mode, a fast 
random access to the encrypted data, and an integrity 

40 check. To this end, the data is encrypted in blocks. The 
size of each block may be a predetermined number or 
specific to the document. For example, the predeter- 
mined number may be a multiple of an actual encryption 
block size used in an encryption scheme. One of the 

45 examples is a block cipher (i.e., a type of symmetric-key 
encryption algorithm that transforms a fixed-length 
block of plaintext (unencrypted text) data into a block of 
ciphertext (encrypted text) data of the same length. This 
transformation takes place under the action of a cipher 

50 key (i.e., a file key). Decryption is performed by applying 
the reverse transformation to the ciphertext block using 
another cipher key or the same cipher key used for en- 
cryption. The fixed length is called the block size, such 
as 64 bits or 128. Each block is encrypted using a CBC 

55 mode. A unique initiation vector (IV) is generated for 
each block. 

[0042] Other encryption of the non-secured data can 
be designed in view of the description herein. In any 
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case, the encryption information and the file key are then 
stored in the security information. One of the important 
features in the present invention is that the integration 
of a header and the encrypted data portion will not alter 
the original meaning of the data that is otherwise not 
secured. In other words, a designated application may 
still be activated when a secured file is selected or 
"clicked". For example, a document "xyz.doc", when se- 
lected, will activate an authoring tool, Microsoft Word, 
commonly seen in a client machine. After the document 
"xyz.doc" is secured in accordance with the present in- 
vention, the resultant secured file is made to appear the 
same, "xyz.doc" that still can activate the same author- 
izing tool, except now the secured file must go through 
a process to verify that a user is authenticated, the user 
has the proper access privilege and sufficient security 
clearance. 

[0043] Another one of the important features in the 
present invention is the use of the protection key. With 
the protection key, the file key can be updated without 
having to modify the key-blocks. For example, the file 
key in the file key block 308 can be updated without hav- 
ing to modify the key-blocks. This feature helps improve 
security of the secured files and make file copy opera- 
tions work faster. 

[0044] FIG. 3B shows an exemplary header structure 
350 of a secured file according to one embodiment of 
the present invention. In general, a header of a secured 
file is a point of entry to the secured file. The header 
structure 350 includes various security information to 
ensure that only an authorized user with sufficient ac- 
cess privilege can access the encrypted data in the se- 
cured file. The security information is cryptographically 
protected or secured. In one embodiment, a good part 
of the header or the security information therein is pro- 
tected by a Message Authentication Code (MAC) that 
can detect any tempering with the header by an unau- 
thorized user without a valid decryption key or CRC 31 6 
of FIG. 3A. 

[0045] The header structure 350 is preferably struc- 
tured in a descriptive language such as a markup lan- 
guage. Examples of such a markup language include 
HTML, WML, and SGML. In a preferred embodiment, 
the markup language is Extensible Access Control 
Markup Language (XACML) that is essentially an XML 
specification for expressing policies for information ac- 
cess. In general, XACML can address fine grained con- 
trol of authorized activities, the effect of characteristics 
of the access requestor, the protocol over which the re- 
quest is made, authorization based on classes of activ- 
ities, and content introspection (i.e., authorization based 
on both the requestor and attribute values within the tar- 
get where the values of the attributes may not be known 
to the policy writer). In addition, XACML can suggest a 
policy authorization model to guide implementers of the 
authorization mechanism. 

[0046] One portion in the header structure 350 is re- 
ferred to as a key block list 352 that may contain one or 



more key blocks. A key block 354 contains an encrypted 
protection key that is sometimes referred to as docu- 
ment/file-encryption-key key, namely a key to the file 
key. To ensure that the protection key is indeed protect- 
5 ed, it is encrypted and can only be retrieved by a desig- 
nated entity. For example, a secured file is created by a 
member of engineering group and permitted for full ac- 
cess by every member in the engineering group. The 
same secured file meanwhile is also permitted for limit- 
10 ed access (e.g., only read and print) by every member 
in the marketing group. Accordingly, the key block list 
352 may include two key blocks, one for the engineering 
group and the other for the marketing group. In other 
words, each of the two key blocks has an encrypted pro- 
fs tection key that can be only accessed by a member of 
the corresponding group (via a group or individual pri- 
vate key). 

[0047] The key block version value 356 provides nec- 
essary details of the encryption algorithm used to pro- 

20 tect the protection key 340. In one embodiment, the 
RSA-OAEP (RSA - Optimal Asymmetric Encryption 
Padding) which is a public-key encryption scheme com- 
bining the RSA algorithm with the OAEP method is 
used. In particular, the uuid of the key pair 358 identifies 

25 a certificate and a private key (the details thereof are 
not shown) that are used to decrypt this value. In addi- 
tion, attributes of the key pair, such as whether the key 
is 1024 or 2048 bits long, are also included to facilitate 
the protection of the protection key 340. 

30 [0048] The block 342 of the header structure 350 in- 
cludes at least three segments 344, 346 and 348. The 
segment 344 includes an encrypted file key that must 
be retrieved in clear to decrypt the encrypted data por- 
tion. The segment 346 includes security level informa- 

35 tion to indicate what security level the secured file is at, 
for example, "top secret", "secret", "confidential" or "un- 
classified" or "none". The segment 348 includes infor- 
mation about the size of the encryption block for the en- 
crypted data portion in the secured file. According to one 

40 embodiment, this is a multiple of the algorithm encryp- 
tion block size. The encrypted data portion is created by 
an encryption with a symmetric key that is called the 
document/file-encryption-key or file key herein. 
[0049] There is another portion 360 of the header 

45 structure 350 that is encrypted by a user or group key. 
The portion 360 (the details thereof are not shown) con- 
tains essentially the access rules embedded with the se- 
cured file to govern who/where the secured file can be 
accessed. Various conditions of accessing the file can 

50 be placed or realized in the access rules. Additional de- 
tails of the access rules can be references in US Patent 
Application No. :1 0/074,804. 

[0050] The above description is based on one embod- 
iment in which the access rules are encrypted with a us- 
55 er's public key. Those skilled in the art can appreciate 
that the access rules may be also encrypted with a file 
encryption key (i.e., the file key) or the protection key. 
In this case, the protection key is encrypted with a user's 
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public key or together with a clearance key associated 
with the user if a subject secured file is secured. Now 
instead of retrieving the protection key after the access 
rules are successfully measured against access privi- 
lege of the user attempting to access a secured file, the 
protection key is retrieved first with a user's private key. 
The protection key can be used to retrieve the access 
rules that are subsequently used to measure against the 
access privilege of the user if the protection key was 
used to encrypt the access rules. If the user is permitted 
to access the contents in the file, the file key is then re- 
trieved with the protection key (or together with the 
clearance key). Alternatively, right after the protection 
key is retrieved, the protection key (or together with the 
clearance key) is used to retrieve the file key. The file 
key is then to retrieve the access rules that are subse- 
quently used to measure against the access privilege of 
the user. In any case, if the user is determined that the 
user has sufficient access privilege in view of all access 
policies, if there are any, the retrieved file key can be 
used to continue the description of the encrypted data 
portion. 

[0051] FIG. 4 there is shown a flowchart of process 
400 for accessing a secured document according to one 
embodiment of the present invention and may be under- 
stood in conjunction with FIG. 3A or FIG. 3B. The proc- 
ess 400 may be implemented in an executable module 
(e.g., document securing module) that can be activated 
when a user intends to access a secured document. For 
example, a user is using a client machine running a Mi- 
crosoft Windows operating system to access a secured 
document stored in a folder, a local, or remote store. By 
activating a Window Explorer or Internet Explorer, the 
user may display a list of files, some are non-secured 
and others are secured. Among the secured files, some 
of them are classified and secured in the manner in ac- 
cordance with FIG. 3A. Within the display of the list of 
files, a desired one can be selected. Alternatively, a de- 
sired file may be selected from an application, for exam- 
ple, using "open" command under File of Microsoft Word 
application. 

[0052] In any case, at 402, such desired document is 
identified to be accessed. Before proceeding with the 
selected document, the process 400 needs to determine 
whether the selected file is secured or non-secured. At 
404, the selected document is examined. In general, 
there are at least two ways to examine the secure nature 
of the selected document. A first possible way is to look 
for a flag or signature at the beginning of the document. 
As described above, in some secured documents, a 
flag, such as a set of predetermined data, is placed in 
the header of a secured document to indicate that the 
document being accessed is secured. If no such flag is 
found, the process 400 goes to 420, namely, the select- 
ed documented is assumed non-secured and thus al- 
lowed to pass and load to a selected application or place 
desired by the user. A second possible way is to look for 
a header in a selected document. Being a secured doc- 



ument, there is a header attached to an encrypted data 
portion. The data format of the header shall be irregular 
in comparison with the selected document if it is non- 
secured. If it is determined that the selected document 

5 has no irregular data format as required by a selected 
application, the process 400 goes to 420, namely, the 
selected document is assumed to be non-secured and 
thus allowed to pass and load to a selected application 
or place desired by the user. 

10 [0053] Now if it is determined at 404 that the selected 
document is indeed secured, the process 400 goes to 
406, wherein the user and/or the client machine being 
used by the user are checked to determine if the user 
and/or the client machine are authenticated. The details 

15 of the user authenticating himself/herself/itself may be 
provided in US Patent Application No. :1 0/074,804. In 
the case that the user and/or the client machine are not 
authenticated, the process 400 goes to 418 that may 
display an appropriate error message to the user. It is 

20 now assumed that the user and/or the client machine 
are authenticated, the header or security information 
therein is decrypted with the authenticated user key. 
[0054] At 408, the access rules in the decrypted se- 
curity information are retrieved. As described above, 

25 there may be sets of access rules, each set designated 
for a particular user or members of a particular group. 
With the authenticated user key and/or a corresponding 
user identifier, a corresponding set of access rules is 
retrieved. At 410, the retrieved access rules are com- 

30 pared to (or measured against) the access privileges as- 
sociated with the user. If the measurement fails, which 
means that the user is not permitted to access this par- 
ticular document, a notification or alert message may be 
generated to be displayed to the user at 418. If the 

35 measurement passes successfully, which means that 
the user is permitted to access this particular document, 
the process 400 moves on to decrypt and retrieve the 
protection key at 411 and then determine if the secured 
document is classified at 41 2. When it is determined that 

40 the secured document is not classified or there is no se- 
curity clearance requirement in the security information, 
the process 400 goes to 416, wherein a file key is re- 
trieved and, subsequently, used to decrypt the encrypt- 
ed data portion in the selected (secured) document. 

45 When it is determined that the secured document is 
classified, the process 400 goes to 414 that checks if 
the authenticated user possesses a clearance key 
matching the security clearance requirement. In gener- 
al, the security level of the clearance key must be equal 

50 to or higher than the security clearance requirement in 
the secured classified document. If the security level of 
the clearance key is not sufficient enough, the process 
400 goes to 418 that can be configured to display an 
appropriate error message to the user. If the security lev- 

55 el of the clearance key is sufficient enough, the process 
400 goes to 416. 

[0055] In any case, a file key is retrieved with the pro- 
tection key alone if the secured document is not classi- 
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f ied or the protection key together with the clearance key 
if the secured document is classified. As a result, the 
decrypted document or clear contents of the selected 
document is provided at 420. 

[0056] FIG. 5 shows a flowchart of a process 500 for 
securing a file or document being created according to 
one embodiment of the present invention. The process 
500 may be understood in conjunction with a client ma- 
chine running a Microsoft Windows operating system. 
However, it is clear to those skilled in the art that the 
description herein or the invention does not imply such 
limitations. 

[0057] At 502, a blank document is opened or created 
by an authoring application chosen and activated by a 
user. The authoring application may be Microsoft Word, 
Microsoft PowerPoint or WordPerfect. In a preferred 
procedure, the user may save the document into a folder 
or a protected store that has already setup with a set of 
access rules. If not, one or more sets of access rules 
may be created. Optionally, the access rules may be re- 
ceived by importation of a previously created file includ- 
ing desirable access rules, defaults of the user access 
privileges or individually created user access privileges. 
At 504, the set of predetermined access rules is re- 
ceived, preferably, in a descriptive language such as a 
plain test or a markup language (e.g., XACML). 
[0058] At 506, a secret cipher key (i.e., a file key) is 
generated from a cipher module for the document and 
typically stored in a temp file that is generally not acces- 
sible by an ordinary user. The temp file will be erased 
automatically when the secured document is done (e. 
g., at a "Close" command from the application). At 508, 
the document is checked to see if a request to write the 
document into a local store is made. If such request is 
detected (which could be made manually by the user or 
periodically by the authoring tool or an OS procedure), 
the document is encrypted with the file key at 51 0. One 
of the features in the present invention is that the stored 
document is always encrypted in storage even if it is still 
being processed (e.g., authored, edited or revised). 
When the user is done with the document, a "Close" re- 
quest is activated to close the document. At 512, such 
a request is detected. As soon as such request is re- 
ceived, it means that a secured version of the document 
needs to be written into the store. At 514, it is assumed 
that the document is classified and that that user who is 
working with the document has been previously as- 
signed a clearance key. The generated file key is then 
encrypted with a protection/clearance key and further 
with a clearance/protection key. The protection key may 
be generated from a cipher module. At 51 6, the protec- 
tion key is encrypted with the authenticated user key. 
[0059] To protect the encrypted protection key, at 51 8, 
appropriate access rules are applied and inserted along 
with the encrypted protection key in the security infor- 
mation that may be further encrypted with the authenti- 
cated user key. The encrypted version of the security 
information is then packed in the header. Depending on 



implementation, aflag or signature can be further includ- 
ed in the header. Alternatively, the header could include 
the security information without a flag. At 520, the head- 
er is attached to or integrated with the encrypted docu- 
5 ment from 51 0 and subsequently the secured document 
is placed into the store at 524. 

[0060] As described above, the secured document in- 
cludes two encrypted portions, the header with encrypt- 
ed security information and the encrypted data portion 

10 (i.e., the encrypted document). The two parts in the se- 
cured documents are encrypted respectively with two 
different keys, the file key and the user key. Alternatively, 
the two encrypted portions may be encrypted again with 
another key (or use the same user key) at 522. 

15 [0061] In the case that there are a number of sets of 
access rules, each for a particular user or a group of 
users, it can be understood that the encrypted access 
rules at 51 8 are integrated with other sets of the encrypt- 
ed access rules in a rules block as illustrated in FIG. 3A. 

20 As such, an access from one user or group will not affect 
other users or groups but the other users or groups will 
see perhaps an updated version of the encrypted doc- 
ument. 

[0062] FIG. 6 shows an exemplary implementation 

25 600 of the present invention. A client machine used by 
a user to access a secured file or secure a created file 
executes an operating system (e.g., WINDOWS 
2000/NT/XP) and may be viewed to have two working 
modes, one being the user mode and the other being 

30 the OS mode. A client module 602 representing an ex- 
ecutable version of the present invention is configured 
to interact with and operate within an operating system 
604 to ensure that a document is made secured and a 
secured document can be accessed only by an author- 

35 ized user. One of the features of the client module 604 
is that the operations thereof are transparent to the user. 
In other words, the user is not made aware of the oper- 
ations of the client module 604 when accessing a se- 
cured document or securing a document. 

40 [0063] An application 606 (e.g. a registered applica- 
tion, such as Microsoft Word) operates in the user mode 
or the OS 604 and may be activated to access a docu- 
ment stored in a store 608. The store 608 may be a local 
storage place (e.g., hard disk) or remotely located (e.g., 

45 another device). Depending on the security nature (se- 
cured vs. non-secured) of the document being ac- 
cessed, the client module 602 may activate a key store 
609 (or an interface thereto) and a cipher module 610. 
The key store 609 retains an authenticated user key af- 

50 ter the user is authenticated. If the user has the need to 
access some secured classified files, the key store 609 
may retain a corresponding clearance key. Depending 
on implementation, the key store 609 may be configured 
to retrieve a clearance key from another location or ac- 

55 tivate a clearance key from an encrypted version there- 
of. The cipher module 610 implements one or more en/ 
decryption schemes and is, preferably, modular so that 
a different cipher module implementing alternative en/ 
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decryption schemes may be readily used, if desired. 
[0064] According to one embodiment, the client mod- 
ule 202 is analogous in many ways to a device driver 
that essentially converts more general input/output in- 
structions of an operating system to messages that a 
device/module being supported can understand. De- 
pending on the OS in which the present invention is im- 
plemented, the client module 602 may be implemented 
as a VxD (virtual device driver), a kernel or other appli- 
cable format. 

[0065] In operation, the user selects a document that 
is associated with an application 606 (e.g., MS WORD, 
PowerPoint, or printing). The application 606 acts on the 
document and calls an API (e.g., createFile, a Common 
Dialog File Open Dialog with Win32 API in MS Windows) 
to access the installable file system (IFS) manger 612. 
If it is detected that an "Open" request is made from the 
application 206, the request is passed to an appropriate 
file system driver (FSD) 614 to access the requested 
document. When it is detected that the requested doc- 
ument is secured, the key store 209 and the cipher mod- 
ule 610 are activated and an authenticated user (pri- 
vate) key is retrieved. The encrypted security informa- 
tion in the header of the requested secure document is 
decrypted with the user key. Now the access rules in the 
secured document are available, a rules measurement 
is carried out in the client module 602 to determine if the 
user is permitted to access the selected secured docu- 
ment. If the measurement is successful, that means the 
user is permitted to access the secured document, a file 
key is retrieved from the security information with a re- 
trieved protection key as well as the clearance key and, 
subsequently, the cipher module 610 proceeds to de- 
crypt the encrypted document (i.e., the encrypted data 
portion) in the client module 602. The clear contents are 
then returned to the application 606 through the IFS 
manager 612. For example, if the application 606 is an 
authoring tool, the clear contents are displayed. If the 
application 606 is a printing tool, the clear contents are 
sent to a designated printer. 

[0066] In another embodiment, an operating system 
(OS) access, known as the ProcessID property, can be 
used to activate an application (as an argument to the 
AppActivate method). The parameter ProcessID identi- 
fies the application and an event handler thereof takes 
necessary parameters to continue the OS access to the 
Installable File System (IFS) Manager 612 that is re- 
sponsible for arbitrating access to different file system 
components. In particular, the IFS Manager 612 acts as 
an entry point to perform various operations such as 
opening, closing, reading, writing files and etc. With one 
or more flags or parameters passed along, the access 
activates the client module 602. If the document being 
accessed by the application is regular (non-secured), 
the document will be fetched from one of the File System 
Driver (FSD) (e.g., FSD 614) and passed through the 
client module 602 and subsequently loaded into the ap- 
plication through the IFS Manager 612. On the other 



hand, if the document being accessed by the application 
is secured, the client module 602 activates the key store 
609 and the cipher module 61 0 and proceeds to obtain 
an authenticated user key to retrieve the access rules 

5 therein. Pending the outcome from the access test mod- 
ule 609, a file key may be retrieved to decrypt the en- 
crypted data portion of the secured document by the ci- 
pher in the cipher module 61 0. As a result, the data por- 
tion or the document in clear mode will be loaded into 

10 the application through the IFS Manager 612. 

[0067] The present invention has been described in 
sufficient details with a certain degree of particularity. It 
is understood to those skilled in the art that the present 
disclosure of embodiments has been made by way of 

15 examples only and that numerous changes in the ar- 
rangement and combination of parts may be resorted 
without departing from the spirit and scope of the inven- 
tion as claimed. Accordingly, the scope of the present 
invention is defined by the appended claims rather than 

20 the foregoing description of embodiments. 



Claims 

25 1 . in a system for providing restrictive access to elec- 
tronic data, wherein the electronic data is structured 
in a format that controls access to contents in the 
electronic data, the format comprising:- 

30 a header including security information control- 

ling the access to the contents in the electronic 
data, wherein the security information includes 
at least a first key and a second key, the second 
key is used to encrypt the first key, the second 

35 key is encrypted and the encrypted second key 

is guarded by access rules; 
an encrypted data portion generated by en- 
crypting the electronic data with the first key ac- 
cording to a predetermined cipher scheme; and 

40 

wherein the header is integrated with the en- 
crypted data portion to generate a secured file. 

2. A format according to Claim 1 , wherein the access 
45 rules are displayable in an application to display ac- 
cess restrictions in the secured file. 

3. A format according to Claim 1 or 2, wherein the ac- 
cess rules are further encrypted and included in the 

50 security information. 

4. A format according to any preceding claim, wherein 
the second key is used to encrypt the first key ac- 
cording to the predetermined cipher scheme and 

55 the encrypted first key is protected by security clear- 
ance information controlling restrictive access to 
the first key. 
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5. A format according to Claim 4, wherein the security 
clearance information is another encryption of the 
encrypted first key such that the first key can only 
be retrieved with both the second key and a clear- 
ance key associated with a user attempting to ac- 
cess the secured file. 

6. A format according to Claim 5, wherein the security 
clearance information is related to a special access 
policy such that the first key can only be retrieved 
with the second key and a successful test of the 
special access policy against access privilege of a 
user attempting to access the secured file. 

7. A format according to Claim 6, wherein the first key 
is a file key that can be used to encrypt as well as 
decrypt the encrypted data portion, and the second 
key is a protection key designated to protect the file 
key in conjunction with a clearance key associated 
with a user attempting to access the secured file. 

8. A format according to Claim 7, wherein the second 
key is encrypted and protected by access rules and 
the access rules are further encrypted and included 
in the security information of the header. 

9. A format according to Claim 8, wherein the encrypt- 
ed access rules can be decrypted with a user key 
associated with the user attempting to access the 
secured file. 

10. A format according to any preceding claim, wherein 
the file key can be retrieved only when the user has 
the clearance key. 

11. A format according to Claim 10, wherein the en- 
crypted first key can be updated without having to 
retrieve the second key. 

12. In a system for providing restrictive access to elec- 
tronic data, wherein the electronic data is structured 
in a format that controls access to contents in the 
electronic data, a method for securing the electronic 
data in the format, the method comprising: 

generating an encrypted data portion by en- 
crypting the electronic data with a first key ac- 
cording to a predetermined cipher scheme; 
encrypting the first key with a second key, if the 
electronic data is not classified; 
encrypting the first key with the second key to- 
gether with a clearance key, if the electronic da- 
ta is classified; 

encrypting the second key to produce an en- 
crypted version of the second key; 
applying access rules to protect the encrypted 
version of the second key; and 
integrating a header with the encrypted data 



portion to produce a secured file, wherein the 
header includes the encrypted first key, the en- 
crypted second key and the access rules. 

5 13. A method according to Claim 12, wherein the ac- 
cess rules can be decrypted only with an authenti- 
cated user key associated with the user attempting 
to access the contents of the electronic data. 

10 14. A method according to Claim 12 or 13, wherein the 
generating of the encrypted data portion compris- 
es:- 

determining a block size of blocks that are used 
15 to divide respectively the electronic data; and 

encrypting each of the blocks according to the 
predetermined cipher scheme. 

15. A method according to any one of Claims 12-14, 
20 wherein the encrypting of the first key with the sec- 
ond key together with the clearance key, if the elec- 
tronic data is classified, comprises:- 

encrypting the first key with the second key to 
25 produce an initial encrypted version of the first 

key; and 

encrypting the initial encrypted version of the 
first with the clearance key to produce the en- 
crypted version of the first key. 

30 

16. A method according to any one of Claims 12-14, 
wherein the encrypting of the first key with the sec- 
ond key together with the clearance key, if the elec- 
tronic data is classified, comprises:- 

35 

encrypting the first key with the clearance key 
to produce an initial encrypted version of the 
first key; and 

encrypting the initial encrypted version of the 
40 first with the second to produce the encrypted 

version of the first key. 

17. A method according to any one of Claims 12-16, 
wherein the clearance key corresponds to a confi- 

45 dential level that determines what classified se- 
cured files the clearance key can be used to retrieve 
the first key. 

1 8. A method according to Claim 1 7, wherein the clear- 
so ance key can be used together with the second key, 

if the access rules have been applied successfully 
against access privilege of a user attempting to ac- 
cess the contents in the electronic data, to retrieve 
the first key in the secured file classified at or lower 
55 than the confidential level of the clearance key. 

19. A method for accessing secured electronic data 
structured in a format that controls access to con- 
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tents in the electronic data, the method comprising:- 

obtaining an authenticated user key associated 
with a user attempting to access the electronic 
data; 5 
retrieving access rules embedded in the format 
to determine if the user has proper access priv- 
ilege; 

retrieving a second key if the user is permitted 

to access the electronic data; 10 

if the content in the electronic data is classified:- 

obtaining a clearance key associated with 
the user; 

using the second key and the clearance 15 
key to ultimately retrieve a first key; 

if the content in the electronic is not classified:- 

using the second key to retrieve a first key; 
decrypting, using the first key, an encryp- 
tion data portion representing an encrypted 
version of the electronic data. 

20. A method according to Claim 19, wherein the ac- 
cess rules are encrypted. 

21 . A method according to Claim 1 9 or 20, wherein the 
retrieving access rules comprises:- 

decrypting the access rules with the authenti- 
cated user key; and 

testing if access privilege of the user is within 
the access rules. 

22. A method according to Claim 1 9, wherein the using 
of the second key and the clearance key to ultimate- 
ly retrieve the first key comprises:- 

obtaining the first key by sequentially using ei- 40 
ther the second key and the clearance key to 
decrypt an encrypted version of the first key or 
the clearance key and the second key to de- 
crypt an encrypted version of the first key. 

45 

23. A software product to be executed in a computing 
system for providing restrictive access to electronic 
data, wherein the electronic data is structured in a 
format that controls access to contents in the elec- 
tronic data, the software product comprising:- so 



program code for encrypting the first key with 

the second key together with a clearance key, 

if the electronic data is classified; 

program code for encrypting the second key to 

produce an encrypted version of the second 

key; 

program code for applying access rules to pro- 
tect the encrypted version of the second key; 
and 

program code for integrating a header with the 
encrypted data portion to produce a secured 
file, wherein the header includes the encrypted 
first key, the encrypted second key and the ac- 
cess rules. 



24. A software product to be executed in a computing 
system for providing restrictive access to electronic 
data, wherein the electronic data is structured in a 
format that controls access to contents in the elec- 
20 tronic data, the software product comprising :- 



program code for obtaining an authenticated 
user key associated with a user attempting to 
access the electronic data; 
program code for retrieving access rules em- 
bedded in the format to determine if the user 
has proper access privilege; 
program code for retrieving a second key if the 
user is permitted to access the electronic data; 
if the contents in the electronic data is classi- 
fied:- 



30 



35 



program code for obtaining a clearance 
key associated with the user; 
program code for using the second key and 
the clearance key to ultimately retrieve a 
first key; 

if the contents in the electronic is not classified; 

program code for using the second key to 
retrieve a first key; 

program code for decrypting, using the first 
key, an encryption data portion represent- 
ing an encrypted version of the electronic 
data. 



program code for generating an encrypted data 
portion by encrypting the electronic data with a 
first key according to a predetermined cipher 
scheme; 

program code for encrypting the first key with a 
second key, if the electronic data is not classi- 
fied; 
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